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The  echo  response  to  key  depressions  shall  be  immediate,  about  50  msec.  For  minor  actions, 
the  reponse  times  shall  be  about  1  sec.,  but  2-4  sec.  are  tolerable.  The  response  time  for  major  actions 
(rearrange  display  or  reformat  a  graph)  are  (and  the  user  typically  expects)  longer  and  more  variable, 
up  to  10  sec. 

2.7.4  Tasks  and  Feedback 

Each  task  must  have  a  definite  beginning  and  end.  After  each  task  the  system  must  return 
to  a  clearly  defined  “home  state."  The  sequence  in  which  information  is  presented  shall  be  logical, 
in  terms  of  the  display  itself  and  in  terms  of  the  user's  task. 

Spacing  and  blanks  in  a  display  are  important  to  maintain  logical  sequencing,  to  reduce  clut¬ 
ter,  and  to  aid  in  recognition  of  items  of  information.  Within  a  given  action  the  user  should  only 
need  to  focus  or  concentrate  on  one  given  area  of  the  screen. 

It  shall  be  possible  for  the  experienced  operator  to  suppress  lengthy  and  repetitive  menus, 
even  though  they  are  deemed  appropriate  for  the  novice. 


EXECUTIVE  SUMMARY 


In  FY82,  the  Pattern  Analysis  Branch,  Mapping,  Charting  and  Geodesy  Division  of  the  Naval 
Ocean  Research  and  Development  Activity  (NORDA)  began  work  for  the  Defense  Mapping  Agency 
(DMA)  on  four  interrelatet  aspects  of  computer-assisted  geographic  names  processing: 

•  digital  capture  of  names  and  named  feature  information  from  analog  sources  such  as  maps 
and  gazetteers; 

•  adaptation  of  a  data  base  management  system  for  a  very  large,  product-independent  set 
of  world  geographic  names  and  their  descriptors  to  support  a  variety  of  DMA  products 
and  applications; 

•  word  and  symbol  processing  to  include  editing  text  with  diacritics  and  special  symbols, 
and  document  formatting; 

•  digital  type  layout  on  maps,  gazetteers,  and  other  DMA  products  with  the  associated  data 
selection,  formatting,  scaling,  and  type  generation. 

DMA’s  four  original  requirement  statements  are  in  Appendix  B. 

This  work,  referred  to  as  the  Geonames  Processing  System,  will  be  conducted  during 
FY82-FY89.  A  Comprehensive  Coordination  Plan  (Norda  Technical  Note  189)  was  written  in  FY82 
to  provide  a  general  system  description.  The  Geonames  Processing  System  Functional  Design  Specification, 
of  which  this  is  Volume  5,  describes  in  more  detail  a  proposed  system  based  on  requirements  presented 
to  NORDA  by  DMA  Headquarters  and  DMA’s  two  production  centers. 

Concurrent  and  related  development  by  DMA’s  Specif  Program  Office  for  Exploitation  and 
Modernization  is  not  considered  in  this  set  of  reports.  Rather,  /4-comprehensive  system  with  simple 
and  adaptable  standard  interfaces  is  described. 

This  volume  outlines  the  performance  specifications  of  the  Geonames  Processing  System  as 
a  whole.  Stated  requirements  are  either  shared  by  all  four  subsystems,  or  are  developmental  functions. 

r 


w 


* 


I 


1  1  '  ii  ■— 


Ftvwvn 


ACKNOWLEDGMENTS 


This  work  was  sponsored  by  DMA  under  Program  Element  64701B,  with  subtask  title, 
“Geonames  Processing  System.’’  Dennis  Franklin  and  Lt.  Col.  Tom  Baybrook,  both  of  DMAHQ/STT, 
shared  project  management  duties  during  the  writing  of  this  report.  Their  help  in  communicating 
with  DMA's  production  centers  and  providing  information  on  DMA  production  methods  was  in¬ 
strumental  to  this  functional  design.  E>r.  Don  Durham,  head  of  NORDA’s  Mapping,  Charting,  and 
Geodesy  (MC&G)  Division,  and  Dr.  Charles  Walker,  head  of  the  MC&G  Division’s  Pattern  Analysis 
Branch,  contributed  valuable  advice  and  assistance. 


TABLE  OF  CONTENTS 


INTRODUCTION 


v 


SOFTWARE  REQUIREMENTS 

1-1 

1.1  Systems  Software 

1-1 

1.2  Applications  Software 

1-3 

1.3  Diagnostic  Software 

1-3 

2.0  HUMAN  FACTORS  ENGINEERING  2-1 

2.1  Introduction  2-1 

2.2  Human  Engineering  Criteria  2-1 

2.3  Visual  Displays  2-1 

2.4  Interactive  Inputs  and  Cursor  Controls  2-2 

2.5  Workstation  Design  2-2 

2.6  Editor/Task  Considerations  2-2 

2.7  Software  and  Interaction  2-3 

3.0  DOCUMENTATION  3-1 

3.1  Deliverable  Documentation  3-1 

3.2  Miscellaneous  Documentation  3-2 


4.0  ACCEPTANCE  TESTING 

4.1  Test  Plans  and  Procedures 

5.0  SYSTEM  MAINTAINABILITY 

5.1  Hardware  Maintenance 

5.2  Software  Maintenance 

6.0  PERSONNEL  IMPACTS 

6.1  Data  Base  Administrator 

6.2  Systems  Support 

6.3  Applications 

7.0  TRAINING 

7. 1  General 

7.2  Programmer  Training 

7.3  Operator  Training 

7.4  Maintenance  Training 

7.5  Maintenance  Training 


4-1 

4-1 


5-1 

5-1 

5-1 


8.0  MISCELLANEOUS  REQUIREMENTS  8-1 

8.1  T  ransportability  8-1 

8.2  Materials,  Parts,  and  Processes  8-1 

8.3  Emanations  8-1 

8.4  Radio  Frequency  Interface  8-1 

8.3  Product  Markings  8-1 

8.6  Workmanship  8-1 

8.7  Safety  Requirements  8-1 

APPENDIX  A:  REFERENCES  A-l 

APPENDIX  B:  SOFTWARE  DOCUMENTATION  STANDARDS  B-l 

APPENDIX  C:  ANALYSIS  OF  NON-ROMAN  SCRIPT  PROCESSING  C-l 

APPENDIX  D:  ORIGINAL  DMA  REQUIREMENTS  STATEMENTS  D-l 


INTRODUCTION 


a.  Organizations 


Defense  Mapping  Agency  Headquarters  (DMAHQ) 

U.S.  Naval  Observatory 
Washington,  D.C. 

Defense  Mapping  Agency  Hydrographic/Topographic  Center  (DMAHTC) 

6500  Brookes  Lane 
Washington,  D.C. 

Defense  Mapping  Agency  Aerospace  Center  (DMAAC) 

3200  South  Second  St. 

St.  Louis,  Missouri 

b.  Scope 

The  purpose  of  this  report  is  to  describe  system  attributes,  serving  as  a  basis  for  mutual 
understanding  between  the  user  and  the  developer. 

The  Geonames  Processing  Subsystems  are  often  referred  to  in  this  report  by  their  acronyms: 
ASP  (Advanced  Symbol  Processing);  ATP  (Advanced  Type  Placement);  GNDB  (Geographic  Names 
Data  Base);  and  AADES  (Automated  Alphanumeric  Data  Entry  System). 

c.  Background 

In  FY82  the  Pattern  Analysis  Branch,  Mapping,  Charting,  and  Geodesy  Division  of  the  Naval 
Ocean  Research  and  Development  Activity  (NORDA)  began  a  subtask  for  the  Defense  Mapping  Agency 
(DMA)  entitled  “Advanced  Type  Placement  and  Geonames  Data  Base  System  Development,"  a  proj 
cct  encompassing  the  digital  capture,  storage,  edit,  and  display  of  geographic  names.  The  subtask  in 
its  current  form  is  an  amalgamation  of  four  previous  DMA  requirements  for  independent  development 
of  .1  geographic  names  data  base,  a  system  for  high-volume  geographic  names  data  capture,  advanced 
word  and  symbol  processing,  and  automated  type  placement  for  maps  (see  Appendix  B  for  DMA's 
original  requirement  statements).  A  Comprehensive  Coordination  Plan  was  submitted  by  NORDA 
as  a  preliminary  definition  of  the  overall  Geonames  Processing  System  subtasks  and  their  interfaces. 

d.  Description 


The  complete  Geonames  Processing  System  is  comprised  of  four  components  (Fig.  i-1). 

•  The  Automated  Alphanumeric  Data  Entry  System  provides  a  means  of  high-volume 
geographic  names  data  capture.  World  geonames  with  their  corresponding  locations  and 
attributes  will  be  captured  from  both  tabular  and  map/chart  sources  using  raster  scan  and 
optical  character  reading  technologies.  AADES  converts  alphanumeric  data  into  computer 
readable  form  with  a  99%  accuracy  rate.  It  requires  minimum  operator  intervention,  pro 
vides  automated  error  checking,  and  results  in  clean  data  files  for  supervised  merging  with 
the  GNDB. 


Figure  i-1  Geonames  Processing  System  overview 


•  Geographic  Names  Data  Base  stores  world  geonames  and  their  descriptors  in  non-product- 
oriented  files.  It  provides  extensive  query  capabilities  to  support  data  base  updates,  chart 
an,!  gazetteer  compilation,  and  toponymic  research.  The  GNDB’s  ultimate  size  will  be  50-100 
million  geonames. 

•  Advanced  Symbol  Processing.  International  geonames  comprised  of  diacritics  and  special 
symbols  require  specialized  hardware  and  software  for  access,  manipulation,  and  editing. 
ASP  provides  alphanumeric  edit  and  display  of  world  geonames  and  advanced  word  proc¬ 
essing  capabilities  such  as  sorting,  searching,  and  formatting. 

•  Advanced  Type  Placement  automates  the  production  of  map  names  overlays  by  exploiting 
electronic  display  technology  and  the  rule-based  nature  of  cartographic  names  placement. 
ATP  includes  automated  utilities  for  names  selection,  type  composition,  type  placement, 
virtual  map  display,  and  interactive  graphic  edit. 

The  Geonames  Processing  System  responds  to  a  major  need:  it  will  integrate  DMA's  names 
processing  tasks  into  the  digital  map  production  |  ipeline  and  coordinate  all  geonames  processing  ac¬ 
tivities.  Obvious  benefits  are  increased  production  rates  and  lowered  costs.  Overall  accuracy  and  coverage 
should  also  improve  with  the  increased  efficiency  of  such  a  system.  Helpful  utilities  will  raise  toponymic 


researchers’  productivity  levels.  Further  automation  will  be  easier  to  implement  once  the  process  is 
converted  from  manual  to  digital. 


This  Performance  Specification  states  the  requirements  shared  by  all  four  Geonames  Process¬ 
ing  System.  Section  1  describes  software  requirements.  Section  2  states  human  factors  engineering 
criteria.  Documentation  is  discussed  in  Section  3  and  in  Appendix  B.  Acceptance  testing  and  system 
maintainability  are  covered  in  Sections  4  and  5,  respectively.  Personnel  impacts  and  training  are  discussed 
in  Sections  6  and  7.  miscellaneous  requirements  are  stated  in  Section  8.  Appendix  C  discusses  methods 
of  handling  non-Romanized  names. 

e.  Applicable  Documents 

The  following  references  provide  a  summary  of  the  basis  for  the  Geonames  Processing  Subc 
task  development. 

•  “Advanced  Type  Placement  and  Geonames  Database:  Comprehensive  Coordination  Plan.” 
NORDA  Technical  Note  189,  January  1983. 

•  “A  Prototype  Geographic  Names  Input  Station  for  the  Defense  Mapping  Agency.”  Paper 
presented  at  Auto  Carto  IV  by  D.R.  Caldwell  and  D.E.  Strife,  September  1982. 

•  “Names  Type  File  System.”  Consulting  Report  for  the  U.S.A.E.T.L  Project  #P0013,  April 
1983. 

•  “Development  of  an  Automated  Cartographic  Capability.”  The  Final  Report  of  the 
Automated  Cartography  Task  Force,  Defense  Mapping  Agency  Hydrographic/Topographic 
Center,  April  1982. 

•  “The  Feasibility  of  Establishing  an  Automated  Chart  Production  Process.”  I  .  Deter.-- 
Mapping  Agency  Hydrographic/Topographic  Center,  October  1982. 

f.  Limitations 


The  individual  subsystem  descriptions  are  functional  and  not  physical  definitions,  i.e.: 

•  a  given  function  required  by  a  given  subsystem  may  not  be  performed  upon  the  hardware 
logically  associated  with  the  subsystem, 

•  one  software  module  may  serve  several  of  the  subsystem  functional  requirements. 

Thus  the  functions  and  data  sets  specified  in  this  five-volume  set  of  design  specifications  are  described 
somewhat  redundantly  to  fully  define  each  subsystem  regardless  of  its  interplay  with  other  subsystems. 
Physical  (hardware  and  software)  synthesis  will  be  accomplished  and  described  by  the  Implementation 
Plan  at  a  later  date. 


1.0  SOFTWARE  REQUIREMENTS 


1.1  Systems  Software 

Systems  software  includes  the  operating  system,  compilers,  assembllrs,  file  management,  and 
tools  or  software  packages  developed  or  acquired  under  this  contract  for  software  development,  update, 
or  maintainance. 

1.1.1  General  Requirements 


Compatibility  is  required  between  the  software  and  the  hardware.  System  software  must  in¬ 
clude  all  executable  code.  A  source  tape  and  program  listings  of  the  operating  system  are  preferred; 
this  is  not,  however,  a  requirement.  I/O  packages  for  each  device  on  the  system  are  to  be  included 
as  part  of  the  operating  system.  Executable  code  for  all  software  must  be  delivered  in  both  disk  and 
magnetic  tape  format.  Errors  found  in  the  software  shall  be  corrected  by  the  developer  for  twelve 
months  after  acceptance. 

Technical  reference  manuals  containing  a  complete  description  of  each  software  module  must 
be  provided.  The  developer  shall  issue  amendments  to  the  technical  reference  manuals. 

1.1.2  Operating  System  Software 

The  operating  system  shall  be  a  disk  oriented,  multi  programming,  real-time  system.  The 
operating  system  must: 

-  load  and  e'  ^cute  disk  library  programs, 

-  add  and  delete  library  programs, 

-  maintain  library, 

-  interface  with  operator  through  assignable  devices, 

-  control  all  standard  peripheral  equipment, 

-  address  logical  files  through  program  or  operator  assignment, 

-  block  and  unblock  data  records, 

-  generate  a  cross  reference  table, 

-  interrupt  driven,  concurrent  operation  of  slow-speed  peripherals  or  da, a  communications 
equipment,  and 

-  compile,  assemble,  link,  and  load  programs  in  real-time  while  executing  other  tasks. 

1.1.3  Assembler 


If  an  assembler  is  required,  a  macro  processor  must  be  included.  Source  language  shall  provide 
operation  codes,  assembly  directed  pseudo-coding  and  symbolic  addressing.  The  assembler  program  must: 

-  print  out  and  assign  storage  for  user-defined  symbols, 

-  flag  illegal  instruction  and  coding  errors, 

-  allow  for  alphanumeric  literals,  and 

-  permit  assignment  of  symbolic  addressing  to  specific  relative  or  absolute  storage  locations. 

1.1.4  Higher  Level  Programming  Language 

The  system  shall  include  at  least  one  higher  level  language  compiler.  This  compiler  must  be 
fully  compatible  with  the  operating  system  requirements  stated  in  Section  1.1.2.  The  programming 
language  must: 


-  read  and  write  a  multiple  disk  file  with  interleaved  records  residing  on  one  or  more  disks, 

-  access  any  peripheral  devices  through  system  support  utilities  in  a  device-independent  mode, 

-  operate  with  a  multi-level  segmented  (overlay)  program  using  both  disk -resident  and  emory- 
resident  segments, 

-  allow  assembly  language  calls  or  function  overlays  from  programs  that  permit  assembly 
language  character  or  byte  manipulation,  and  access  to  system  device  handlers,  or  handle 
these  functions  via  specialized  instructions, 

-  use  all  CPU  memory  not  used  by  the  operating  system. 

-  accept  in-line  assembly  language  routines,  or  function  overlays. 

-  allow  reading  or  writing  of  unformatted  binary  tapes  from  other  computers,  such  as  an 
equivalent  to  “buffer  in”  or  “buffer  out”  statements, 

-  allow  reading  or  writing  of  tapes  containing  industry  standard  format  ASCII. 

-  write  and  read  random  and  sequential  files,  both  fixed  and  variable  length,  as  well  as  formatted 
and  unformatted. 

Applications  routines  must  not  be  written  in  assembler  language  when  they  reasonably  could  be  coded 
in  a  higher  level  language. 

1.1.5  Utilities 


The  following  utilities  shall  be  provided  as  a  part  of  the  operating  system  software. 

1.1. 5.  a  File  Manager 

The  file  manager  is  for  creating,  reading,  writing,  duplicating,  and  purging  named  files.  It 
includes  capabilities  to: 

-  read  and  write  files  and  records: 

-  read  and  write  fixed-length,  variable-length  and  undefined  length  records: 

allocate  multiple  disk  files  to  a  job  and  have  these  files  open  for  access  simultaneously: 

-  make  device  drivers  core-resident  for  support  of  selected  programs. 

l.l.i.b  Text  Editor 

The  text  editor  interactively  edits  programs  and  files. 

1.1. 5. c  Debuggers 

Debuggers  arc  used  by  programmers.  Complete  documentation  of  debuggers  and  other  such 
aids  is  required. 

1.1. 5. d  Scientific  Library 

The  scientific  library  must  be  callable  from  the  high-level  programming  language.  It  must 
include  a  listing  of  all  functions,  including  a  description  of  each  function  and  its  accuracy  limitations. 


1.1.5  e  Fill  Copy/Dump  Utilities 

Routines  for  input/output  and  data  transfer  from  one  device  to  another,  for  all  applicable  devices 
must  lie  provided. 
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1.1.6  Graphics  Display  Software 


The  graphics  software  package  shall  include  all  drivers  needed  to  interface  the  device  with 
the  specific  computer.  Graphics  routines  shall  be  accessed  efficiently  through  program  calls. 

1.2  Applications  Software 


The  functional  specifications  of  the  applications  software  used  by  individual  systems  are  described 
in  the  other  four  volumes  of  this  Functional  Design  Specification. 

All  applications  software  necessary  for  the  operation  of  the  Geonames  Processing  System  shall 
be  provided.  The  programs  must  be  modular,  use  top-down  structured  programming  techniques  and 
be  coded  in  a  high-level  programming  language  to  the  maximum  extent  possible.  There  shall  be  a 
minimum  of  assembly  language  employed.  Both  source  and  executable  code  for  all  applications  soft¬ 
ware  programs  shall  be  delivered.  These  programs  shall  be  documented  in  accordance  with  [1]  to  in¬ 
clude  at  a  minimum  the  Users  Manual  (Part  2,  2.4.6),  the  Functional  Description  (Part  2,  2.4.1).  the 
Program  Specification  (Part  2,  2.4.4),  the  Computer  Operation  Manual  (Part  2,  2.4.7),  and  the  Pro¬ 
gram  Maintenance  Manual  (Part  2,  2.4.8). 

Interactive  applications  software  shall  be  operator  oriented.  Printed  outputs  shall  be  clearly 
formatted  and  labeled.  Program  options  shall  be  resolved  via  software  interaction  with  analysts  at  their 
workstations  or  consoles.  It  shall  be  possible  to  interrupt  a  program  to  change  an  option. 

The  software/firmware  shall  automatically  guard  against  accidental  damage  to  any  system  com 
ponent  due  to  software  or  control  key  error.  All  operator  error  codes  shall  be  output  to  the  appropriate 
workstation  or  console  as  clear  diagnostic  messages.  The  system  shall  have  a  means  of  easy  recovery 
from  operator  error  (e.g.,  wrong  function  key  hit). 

When  an  analyst  tries  to  delete  or  modify  significant  portions  of  the  data  being  treated,  the 
software  will  require  the  command  to  be  entered  twice  to  allow  the  analyst  to  double  check  his  inten 
tions  before  the  action  is  implemented. 

1 .3  Diagnostic  Software 

1.3.1  CPU/Peripheral  Diagnostics 

A  complete  set  of  diagnostic  programs  for  determining  problems  in  the  CPU  and  peripherals 
must  be  provided  along  with  reference  manuals  to  facilitate  periodic  testing  by  the  operator  and 
maintenance  personnel. 

1.3.2  Edit  System  Diagnostics 

Diagnostic  programs  shall  be  supplied  that  systematically  test  all  special  hardware  (graphic 
tablets,  function  keyboard,  etc.).  This  software  shall  locate  malfunctions  to  the  least  replaceable  unit  (LRU). 

1.3.3  Microdiagnostics 

In  keeping  with  state-of-the-art  requirements,  “Maintenance  Microdiagnostic"  programs  arc 
to  be  proposed  when  applicable.  These  programs  shall  provide  for  individual  integrated  circuit  testing 
wherever  possible.  Development  of  new  microdiagnostics  for  the  Geonames  Processing  System  will 
not  be  required. 


2.0  HUMAN  FACTORS  ENGINEERING 


2.1  Introduction 

The  Geonames  Processing  System  shall  be  operable  and  maintainable  in  a  comfortable,  effi¬ 
cient,  effective  and  safe  manner.  Human  factors  engineering  standards  as  set  forth  in  military  specifica¬ 
tions  must  be  applied  through  all  phases  of  equipment  design,  development,  and  test. 

i 

The  objectives  of  human  factors  engineering  are  efficient,  effective  and  safe  performance  by 
operator,  control  and  maintenance  personnel;  to  minimize  skill  and  personnel  requirements  and  train 
ing  time;  a  reliable  the  man-machine  interface;  and  design  standardization  within  and  among  systems. 

To  accomplish  the  above  objectives,  system  developers  will  insure  that  human  engineering 
standards  are  being  followed.  They  must  examine  the  facilities  and  environment  in  which  the  system 
will  be  used  and  recommend  work  space  arrangement.  For  easy  system  use,  developers  must  prepare 
operator  and  maintenance  manuals  and  training  plans,  and  modify  documentation  if  there  are  design 
changes. 


Ease  of  use,  operator  convenience,  and  error-prevention  shall  be  primary  considerations  of 
the  hardware  and  software  design  of  the  Geonames  Processing  System.  The  physical  configuration 
of  the  hardware  components  of  a  workstation  shall  be  designed  to  facilitate  comfort  and  ease  of  long 
term  operation.  An  operator  may  be  using  the  system  several  hours  at  any  one  time.  Consequently, 
the  system  environment  shall  be  designed  to  minimize  operator  fatigue. 

2.2  Human  Engineering  Criteria 

The  requirements  set  forth  in  MIL  SPEC  1472C,  “Human  Engineering  Design  Criteria  for 
Military  Systems,  Equipment  and  Facilities”  [15]  shall  be  followed. 

Should  it  become  necessary  to  deviate  from  human  engineering  standards  in  MIL  SPEC  1472C 
or  if  there  are  human  engineering  problems  which  cannot  be  resolved,  a  request  for  changes  or  guidelines 
will  be  sought  from  the  Defense  Mapping  Agency. 

2.3  Visual  Displays 

Ideally,  the  visual  display  devices  shall  be  large  with  high  resolution  and  very  low  distortion, 
jitter,  and  noise  for  optimal  visual  detection  of  anomalies  and  discrepancies  and  accurate  data  modifica¬ 
tion.  Relatively  fast  write  and  erase  times  are  required  to  reduce  task  execution  times. 

Some  of  the  critical  human  factors  considerations  that  should  be  considered  for  the  display 
device  are: 

-  resolution, 

-  number  of  shades  of  gray  (or  color,  if  applicable), 

-  size  of  display, 

-  fineness  of  grid  (related  to  resolution), 

-  response  rate, 

-  write  and  erase  speeds, 

-  number,  size,  and  legibility  of  characters  and  symbols, 

-  selective  erase, 

-  pan  and  zoom  characteristics, 


-  image  distortion, 

-  image  drift,  jitter,  and  flicker, 

-  adjustable  contrast  and  brightness, 

-  viewing  distance, 

-  viewing  angle, 

-  registration,  and 

-  nonglare  screens  or  hoods. 

2.4  Interactive  Inputs  and  Cursor  Controls 

i 

Various  interactive  input  and  pointing  devices  are  required,  including  a  standard  keyboard, 
a  set  of  function  and  mode  keys,  and  controls  for  manipulating  displays  and  cursors. 

2.4.1  Keyboard,  Function,  and  Mode  Keys 


A  standard  keyboard  shall  be  provided  for  interactive  communications  with  the  computer  and 
text  processor.  This  keyboard  shall  be  movable  within  a  short  range  of  the  displays.  Function  keys 
shall  be  logically  arranged  and  conveniently  located  relative  to  the  keyboard  and  display. 

2.4.2  Cursor  Controls 


In  designing  the  cursor  controls,  the  following  should  be  considered: 

-  ability  to  locate,  pick,  draw,  move  items,  input  values,  etc.; 

-  ease  of  manipulating  and  moving  controls; 

-  speed  of  cursor  movement; 

-  accuracy  of  cursor  positioning; 

-  facility  for  making  small  incremental  moves; 

-  device  location. 

2.5  Workstation  Design 

The  criteria  in  paragraph  2.2  shall  be  met  in  the  workstation  designs.  Space  must  be  allowed 
for  reference  materials,  photography,  manuscripts,  hardcopy  plots,  reports,  etc. 

2.6  Editor/Task  Considerations 

Important  editor  characteristics  are: 

-  visual  acuity, 

-  visual  fatigue  susceptibility, 

-  hand/eye  coordination, 

-  alertness, 

-  detection  skills, 

-  motivations, 

-  knowledge  of  tasks  and  subtasks, 

-  knowlldge  of  anomalies  and  discrepancies, 

-  knowledge  of  symbol  meanings, 

-  cartographic  skills  and  knowledge. 


Important  task  considerations  are: 


-  complexity  of  task  and  subtasks, 

-  time  to  complete  task  and  subtasks, 

-  complexity  of  visual  displays, 

-  demands  on  cartographic  abilities, 

-  demands  on  artistic  abilities, 

-  accuracy  required, 

-  feedback  of  results, 

-  ability  to  recall  orginal  data. 

2.7  Interactive  Software 

The  following  guidelines  are  tailored  to  the  needs  of  the  system.  The  system’s  users  will  not 
always  be  sophisticated  in  computer  interactions  or  “computer  oriented,”  and  consequently  these 
guidelines,  which  are  intended  to  apply  to  these  types  of  users,  will  be  especially  helpful  to  planners. 
Software  guidelines  are  detailed;  hardware  ones  are  not,  since  workstations  will  have  standard  con 
figurations  and  editor  interaction  with  them  will  be  straightforward  (as  long  as  human  engineering 
standards  have  been  met). 

System  software  shall  be  designed  to  minimize  human  error,  maximize  operator  productivity, 
and  ease  the  task  of  training  new  operators.  Command  entry  shall  be  simple,  requiring  a  minimum 
of  key  strokes,  button  pushes,  etc.,  and  following  a  logical  sequence.  Typed  commands  should  be 
mnemonic,  i.e.,  related  to  their  English  verbs  and  nouns,  with  a  minimum  of  artifical  language.  Com 
mand  logic  shall  be  related  to  the  practices  of  toponymy  and  cartography  for  ease  of  operator  training. 
Command  entry  shall  be  acknowledged  by  the  computer. 

2.7.1  Interactive  Communications 

A  conversational  command  protocol  should  be  maintained,  using  terse  “natural”  language 
and  avoiding  the  use  of  abstract  codes  and  obscure  mnemonics.  Abbreviations  shall  be  allowed  wherever 
possible.  Commands  shall  be  short  so  errors  are  corrected  simply  and  a  reasonable  tempo  is  main 
tained.  If  acronyms  are  used,  they  shall  be  meaningful  to  the  users  without  difficult  memorization, 
such  as  PRT  (print)  rather  than  FUN  1  (function  1). 

Error  messages  shall  be  meaningful  and  informative  and  shall  indicate  the  appropriate  correc 
tive  action.  Manual  data  entry  shall  be  highly  user  oriented.  The  computer  system  shall  give  help 
when  requested.  Control  of  the  processing  tempo  should  always  belong  to  the  user.  The  behavior  of 
the  computer  should  appear  to  be  consistent  under  all  circumstances. 

The  system  shall  adapt  to  the  ability  of  the  user.  The  user  should  be  able  to  control  the  length 
of  cues  or  error  messages  to  suit  his  facility  with  the  system.  In  addition  to  the  user's  control  of  message 
lengths,  the  computer  could  make  some  automatic  adjustments.  Longer,  more  elaborate  messages  could 
be  supplied  if  the  user  requests  help  frequently  or  makes  more  than  a  few  errors.  Redundancy  in  the 
dialogue  shall  be  avoided  or  reduced,  especially  as  the  user  becomes  more  familiar  with  the  system. 

2.7.2  Errors  and  Changes 

Commands  with  major  effects  (irreversible  change  or  slow  recovery)  shall  never  be  defaults 
and  shall  not  be  easy  to  initiate  accidentally.  The  system  shall  allow  the  user  to  preview  a  change 
before  it  becomes  permanent,  and  allow  for  immediate  and  easy  correction  of  errors  or  unwanted  ac¬ 
tion.  The  system  shall  allow  complete  or  partial  cancellation  in  mifltask  so  that  the  user  can  immediate¬ 
ly  proceed  with  what  he  wants  to  do. 
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2.7.3  Device  Responses 


The  echo  response  to  key  depressions  shall  be  immediate,  about  50  msec.  For  minor  actions, 
the  reponse  times  shall  be  about  1  sec.,  but  2-4  sec.  are  tolerable.  The  response  time  for  major  actions 
(rearrange  display  or  reformat  a  graph)  are  (and  the  user  typically  expects)  longer  and  more  variable, 
up  to  10  sec. 

2.7.4  Tasks  and  Feedback 

Each  task  must  have  a  definite  beginning  and  end.  After  each  task  the  system  must  return 
to  a  clearly  defined  “home  state.”  The  sequence  in  which  information  is  presented  shall  be  logical, 
in  terms  of  the  display  itself  and  in  terms  of  the  user’s  task. 

Spacing  and  blanks  in  a  display  are  important  to  maintain  logical  sequencing,  to  reduce  clut¬ 
ter,  and  to  aid  in  recognition  of  items  of  information.  Within  a  given  action  the  user  should  only 
need  to  focus  or  concentrate  on  one  given  area  of  the  screen. 

It  shall  be  possible  for  the  experienced  operator  to  suppress  lengthy  and  repetitive  menus, 
even  though  they  are  deemed  appropriate  for  the  novice. 
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3.0  DOCUMENTATION 


3.1  Deliverable  Documentation 


A  master  index  of  deliverable  documentation,  software,  and  hardware,  and  final  copies  of 
documentation  shall  be  delivered  60  days  before  hardware/software  delivery.  A  draft  copy  of  the  documen¬ 
tation  shall  be  delivered  120  days  before  hardware/software  delivery.  All  documentation  shall  be  in 
accordance  with  DoD  Standard  7935-1— S  [2]  and  shall  include  items  discussed  below. 

3.1.1  Installation  Information 

Drawings  and  data  indicating  the  space  requirements,  placement  of  units,  floor  loading,  elec¬ 
tric  power,  and  other  information  needed  to  prepare  for  the  installation  of  the  equipment  shall  be 
provided  at  least  six  months  before  hardware  delivery. 

3.1.2  Test  Procedure  Results 


Documentation  of  the  procedures  used  to  demonstrate  compliance  with  this  specification,  and 
records  proving  that  such  compliance  was  demonstrated  prior  to  shipment  and  acceptance,  shall  be 
provided  at  the  time  of  delivery. 

3.1.3  Software  Documentation 


Other  than  proven,  commercially-available  software  packages,  all  software  must  be  documented 
completely.  Software  documentation  must  describe  debugging  aids,  utility  routines,  diagnostic  routines, 
and  operating  system.  In  addition  to  the  requirements  specified  in  [2],  all  application  software  shall 
be  documented  in  the  manner  described  in  Appendix  B.  A  detailed  index  and  flowchart  of  all  software 
modules  to  be  delivered  and  their  degree  of  documentation  shall  be  included  in  the  implementation 
plan.  Eight  copies  of  the  final  documentation  must  be  supplied.  Only  three  hardcopy  program  listings 
need  be  supplied. 

3.1.4  Operator’s  Documentation 

This  shall  include  a  manual  that  describes  operating  the  system  and  contains  operator  maintenance 
procedures.  It  shall  be  in  a  form  easily  understandable  by  the  operator.  A  draft  copy  of  the  manual 
shall  be  furnished  for  DMA  review  before  printing. 

3.1.3  Maintenance  Manuals 


Five  copies  of  a  comprehensive  maintenance  package  shall  be  included  to  test,  detect  and  isolate 
malfunctions  in  all  equipment  units  or  elements  specified  and  delivered  by  the  developer.  Documenta¬ 
tion  pertaining  to  all  peripherals  supplied  by  the  contractor,  subcontractors,  and  vendors  on  all  sup¬ 
plied  equipment  and  subsystems  shall  be  included.  The  package  shall  contain: 

-  a  system  manual  of  good  commercial  quality, 

-  CPU  and  peripheral  manuals  of  good  commercial  quality, 

-  complete  parts  list  in  each  of  these  manuals. 

3.1.6  Parts  Lists 

A  list  of  those  parts  necessary  to  maintain  the  system  for  a  period  of  one  year  shall  be  provid¬ 
ed.  Cost  data  must  be  provided  for  each  item  listed  so  the  parts  may  be  purchased  following  first  equip¬ 
ment  delivery. 
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Price  data  for  support  items  required  for  maintenance,  calibration,  and  alignment  of  equip¬ 
ment,  such  as  alignment  disks  for  disk  units,  shall  be  included  so  the  items  may  be  purchased  following 
first  equipment  delivery. 

It  shall  be  certified  that  all  engineering  changes  announced  by  the  Original  Equipment  Manufac¬ 
turer  (OEM)  have  been  installed  on  the  equipment  at  the  time  of  installation  and  that  equipment  is 
eligible  for  a  maintenance  contract  by  the  OEM. 

3.2  Miscellaneous  Documentation 


AH  future  issuances  (such  as  follow-up  bulletins,  diagnostic  listings,  and  general  documenta 
tion  changes)  published  by  subcontractors  or  material  suppliers  shall  be  passed  to  the  DMA  Maintenance 
Control  Branch  during  the  life  of  the  system. 

3.2.1  Engineering  Drawings 


Engineering  drawings  prepared  by  any  subcontractors  for  fabricating  or  assembling  system 
components  shall  be  delivered  under  the  contract,  as  well  as  layout  drawings  showing  interconnections 
and  mechanical  interfaces.  The  drawings  shall  be  prepared  using  good  commercial  engineering  practices. 


4.0  ACCEPTANCE  TESTING 
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4.1  Test  Plans  and  Procedures 

A  Preliminary  Acceptance  Test  Plan  for  the  system  shall  be  submitted.  The  purpose  of  the 
test  shall  be  to  demonstrate  to  DMA  the  capability,  throughput,  and  reliability  of  the  system.  The 
documentation  of  the  procedures  used  to  demonstrate  compliance  with  specifications,  and  records  prov 
ing  that  such  compliance  was  demonstrated  prior  to  shipment  and  acceptance  shall  be  provided  at 
the  time  of  acceptance.  A  Final  Acceptance  Test  Plan  is  due  6  months  prior  to  hardware/software  delivery. 

4.1.1  DMA  Testing 

In  accordance  with  the  proposed  system  capabilities  stated  in  these  Functional  Design  Specifica¬ 
tions  (FDS),  the  Geonames  Processing  System  shall  accept  input  from  a  variety  of  digital  sources  and 
produce  completed  geonames  products  as  well  as  assisting  in  the  daily  activities  of  the  DMA.  The 
DMA  test  plan  will  include  the  exercise  of  all  system  operations. 

4.1.2  Hardware  Testing  (Mechanical) 

The  system  will  be  given  a  thorough  visual  inspection  and  examination  by  DMA  maintenance 
personnel  to  determine  that  the  quality  of  all  materials  and  workmanship  is  in  compliance  with  the 
requirements  of  these  performance  specifications. 

4.1.3  Hardware  Testing  (Electrical) 

DMA  representatives  will  observe  while  the  system  is  given  electrical  tests  confirming  that 
all  supply  circuits  are  sound.  A  check  shall  be  made  to  insure  the  proper  functioning  of  all  buttons, 
keys,  lights,  and  displays  associated  with  each  device. 
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5.0  SYSTEM  MAINTAINABILITY 


5.1  Hardware  Maintenance 


The  Geonames  Processing  System  shall  be  designed  for  reliable  operation  (with  normal 
maintenance)  for  at  least  ten  years.  It  shall  be  designed  to  operate  for  at  least  100  cumulative  hours 
without  requiring  scheduled  maintenance. 

The  system  shall  be  designed  for  ease  of  maintenance.  All  components  shall  be  easily  accessi¬ 
ble.  Those  components  which  have  short  scheduled  maintenance  periods  shall  be  accessible  to  accom 
modate  quick  replacement. 

The  cost  for  continuous  on-site  hardware  and  software  support  during  the  installation  period 
shall  be  reported  to  DMA  in  order  that  the  Government  may  elect  to  purchase  or  not. 

5.2  Software  Maintenance 


Maintenance  shall  be  provided  for  all  delivered  software.  Maintenance  shall  include  correc 
tions  of  all  software  errors  identified  in  accordance  with  standard  procedures.  In  addition,  all  vendor 
updates  to  standard  off-the-shelf  software  issued  during  the  maintenance  period  shall  be  provided. 
Documentation  shall  be  updated  in  accordance  with  the  documentation  standards  in  Section  3  for  all 
software  modifications. 


6.0  PERSONNEL  IMPACTS  (1) 


Staffing  requirements  for  the  Geonames  Processing  System  fall  into  the  two  categories  of  Ap¬ 
plications  and  Systems  Support  (see  Figure  6-1).  Required  personnel  are: 

-  Data  Base  Administrator 

-  System  Manager 

-  Production  Manager 

-  system  support  staff 

a.  system  programmer 

b.  applications  programmer 

c.  computer  operator 

-  applications  analysts 

a.  cartographers 

b.  toponymists 

6.1  Data  Base  Administrator 

Data  base  administration  may  be  performed  by  an  individual  or  by  executive  committee.  Primary 
responsibilities  include  establishing  and  policing  standards  for  data  size,  format,  and  usage;  administer 
ing  detailed  system  documentation;  and  coordinating  user  needs  in  light  of  current  system  capabilities 
and  data  resource  development.  System  and  production  statistics  are  directed  to  the  Data  Base  Ad¬ 
ministrator  to  assist  in  policy  decisions.  The  role  of  the  Data  Base  Administrator  is  further  detailed 
in  the  GNDB  EDS,  Volume  2  of  this  series,  Section  2.4. 

6.2  System  Support 

6.2.1  System  Manager 

The  System  Manager  has  expertise  in  the  areas  of  computer  systems  and  data  structures  and 
oversees  operational  and  system  support.  He/she  is  familiar  with  the  logical  and  physical  design  of 
the  GNDB  and  with  system  and  applications  software.  His/her  major  function  is  to  oversee  continuing 
software  maintenance  and  upgrades  in  system  and  applications  programming. 

6.2.2  System  Support  Staff 

The  system  support  staff  performs  the  software  maintenance  and  upgrade  tasks  dictated  by 
the  System  Manager.  The  support  staff  is  comprised  of  a  systems  programmer,  an  applications  pro¬ 
grammer,  and  a  computer  operator. 

6.3  Applications 

6.3.1  Production  Manager 

The  Production  Manager  oversees  daily  applications  processes  such  as  toponymic  research 
and  geonantes  product  generation. 


(1)  This  section  was  written  with  the  assistance  of  Dr.  Alan  Barnes,  Planning  Systems.  Inc.. 
McLean,  Va. 
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7.1  General 


Training  courses  shall  include  manuals,  handouts,  and  other  training  aids.  These  materials 
shall  he  over  and  above  the  documentation  listed  in  Section  3.  Title  to  all  training  materials  shall 
pass  to  the  Government  without  restrictions  as  to  reproduction  or  reuse.  Courses  shall  not  run 
concurrently. 

7.2  Programmer  Training 


Application  programmer  training  shall  be  supplied  at  DMA  for  up  to  eight  Government  pesonnel. 
Training  shall  be  completed  prior  to  final  acceptance  of  the  system.  The  course  shall  cover  all  pro¬ 
grams  for  the  system  with  a  complete  discussion  of  their  operation,  maintenance,  and  methods  of  modifica¬ 
tions.  The  course  shall  also  include  a  total  system  overview  to  include  such  subjects  as  interaction 
at  hardware  and  software,  mathematics  and  any  numerical  methods  used  in  the  software. 

System  programmer  training  shall  be  provided  for  four  personnel.  The  training  shall  include, 
but  not  be  limited  to,  program  preparation  and  execution,  operating  systems,  compilers  and  assemblers, 
loaders/linkers,  file  manager,  and  other  support  software. 

7.3  Operator  Training 

Training  for  applications  analysts  in  workstation  operation  shall  be  supplied  at  DMA.  The 
course  will  cover  all  phases  of  operation  of  the  system  and  shall  provide  for  each  analyst  to  become 
sufficently  knowledgeable  about  the  system  to  efficiently  use  all  applications  programs.  A  discussion 
of  the  analyst's  manual  shall  be  included  to  familiarize  the  analyst  with  its  use.  The  system  shall  be 
available  for  practical  experience.  Twenty  analysts  shall  be  trained. 

Training  to  operate  processing  hardware  shall  be  provided  for  the  DMA  personnel.  Training 
for  tour  operators  shall  be  provided. 

7.1  1’roduction  Supervisor  Training 

Training  shall  be  provided  for  ten  individuals  in  the  functions  and  use  of  the  Job  Manager 
as  outlined  in  the  FDS’s.  These  individuals  shall  also  be  given  a  sufficient  overview  and  summary 
oi  the  system  capability  to  tnlly  appreciate  their  responsibility.  At  least  three  individuals  shall  be  fully 
trained  prior  to  beginning  of  acceptance  testing. 

7.3  Maintenance  Training 


Maintenance  training  shall  be  provided  at  DMA  for  five  Government  personnel.  Prerequisite 
for  the  course  will  be  a  knowledge  of  electronics  and  fundamentals  of  programming.  The  course  shall 
inc  lude  a  system  overview,  theory  of  operation,  preventive  and  remedial  maintenance,  a  thorough  discus 
sion  of  the  calibration  and  diagnostic  programs  used  by  the  system,  a  review  of  all  circuit  diagrams 
and  maintenance  manuals,  and  a  review  of  preventive  maintenance  procedures. 

At  the  completion  of  the  maintenance  training,  personnel  shall  be  capable  of  performing  both 
preventive  and  remedial  maintenance  on  all  the  equipment  specified  in  the  system. 
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8.0  MISCELLANEOUS  REQUIREMENTS 


8.1  Transportability 

The  system,  in  a  nonoperating  condition  and  when  packaged  for  shipment,  shall  he  designed 
to  be  transportable  by  common  carrier.  Units  shall  be  capable  of  intrafacility  movement  by  standard 
fork  lift,  in  a  packaged  condition,  fitting  through  an  opening  80  inches  high  by  71  inches  wide. 

8.2  Materials,  Parts,  and  Processes 


System  materials,  parts,  and  processes  shall  be  consistent  with  industry  standards  for  high 
quality  equipment  and  shall  meet  the  life  requirements  of  the  equipment  as  specified. 

8.3  Emanations 

The  system  design  shall  utilize  good  electromagnetic  compatibility  design  practices  in  sup 
pressing  any  potential  noise  generating  (radiated  and  conducted)  sources.  Components  available  with 
noise  suppression  features  shall  be  used  if  possible. 

8.4  Radio  Frequency  Interference  (RFI) 

The  specified  equipment  shall  be  protected  against  Radio  Frequency  Interference  (RFI)  so  dr 
cuits  are  not  adversely  affected  by  RFI  or  voltage  transients.  All  cabling  outside  of  cabinets  will  be 
shielded.  Each  shield  shall  include  a  bare  drain  wire.  This  drain  wire  shall  have  a  lay  such  that  it 
will  make  contact  with  the  shield  throughout  its  length.  A  drain  wire  throughout  the  cable  is  not 
required  in  braided  copper  shielded  cable. 

8.3  Product  Markings 

The  system  and  all  components  shall  be  specified  with  appropriate  markings  containing  prod 
uct  name,  manufacturer's  name,  model  number,  serial  number,  power  requirements.  BTUs.  etc. 

8.6  Workmanship 

The  system  and  all  its  parts  shall  be  fabricated  and  finished  in  a  professional  manner. 

8.7  Safety  Requirements 

The  equipment  should  have  the  lowest  noise  emission  levels  that  are  technologically  and 
economically  feasible  and  compatible  with  performance  and  environmental  requirements.  Noise  levels 
(continuous  or  intermittent)  shall  not  exceed  70  decibels  A-weighted  sound  pressure  level  (dba)  tor 
8  hours  in  any  24  hour  period. 

Access  areas  shall  not  expose  operators  to  moving  parts  during  machine  operation  or  when 
operator  access  covers  are  open.  Limit  switches  shall  be  provided  for  all  motions  to  prevent  damage 
to  the  equipment  in  the  event  of  component  malfunction  or  operator  error. 
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1 1.  Federal  Information  Processing  Standard  Publication  (FIPS  PUB)  22.  Synchronous  Signaling  Rates 
Between  Data  Terminal  and  Data  Communication  Equipment. 

1 2.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  36.  Graphic  Representation 
of  the  Control  Characters  of  ASCII. 

13.  Federal  Information  Processing  Standards  Publications  (FIPS  PUB)  37,  (FED-STD  10010,  Svn 
chronous  High  Speed  Data  Signaling  Rates  Between  Data  Terminal  Equipment  and  Data  Com 
munications  Equipment. 

14.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  50,  Recorded  Magnetic  Tape 
for  Information  Interchange  6250  CPT  (246  CPMM).  Group  Coded  Recording. 
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APPENDIX  B 

SOFTWARE  DOCUMENTATION  STANDARDS 

Documentation  required  for  all  systems  or  programs  written  for  DMA  includes  the  following: 

-  system  documentation, 

-  program  documentation, 

-  subroutine  documentation, 

-  comments  in  the  code,  and 

-  appendices. 


B.  I  System  Documentation 

r 

The  narrative  begins  with  an  overview  of  the  system.  This  shall  include  system  name,  pro¬ 
grammer,  date  written,  language,  purpose,  and  method.  A  diagram  is  also  required  that  describes  the 
overall  logic  flow  of  the  system.  This  diagram  shall  indicate  linkages  between  work  flow,  job  manage¬ 
ment.  procesors.  and  programs.  A  description  of  all  files,  tables,  special  tape  formats,  labeled  and  blank 
commons,  and  math  models  used  shall  be  included  in  an  appendix  to  the  document.  Formats  or  assign 
ment  of  specific  files  for  certain  functions  shall  be  given.  An  example  of  this  would  be:  “Tape  -1  is 
used  as  output." 


The  following  titles  shall  be  used  when  applicable: 

SYSTEM  NAME: 

PROGRAMMER/S: 

DATE:  Date  completed— month,  day,  year 

LANGUAGES:  eg.  FORTRAN,  ASSEMBLER 


PURPOSE:  Overall  purpose  and  function  of  system. 

METHOD:  How  the  system  works,  including  the  flow’  and  structure. 

COMMON,  TABLES,  FILES:  Name  of  all  tables  and  files  that  are  fully  outlined  in  the 

appendix. 


COMPUTER: 


B.2  Program  Documentation 

This  narrative  is  a  description  of  the  main  program.  It  includes  a  flow  chart  and  an  explana 
tion  ot  how  the  program  works.  This  explanation  shall  follow  the  logic  of  the  program  and  correlate 
with  the  comments  in  the  code.  All  input  and  output  parameters,  externals,  and  error  codes  shall 
be  included  and  explained  in  the  system  documentation.  All  blank  and  labeled  common  shall  be  described 
in  an  appendix. 


c 


in 


The  following  titles  shall  be  used: 


PROGRAM  NAME: 
PROGRAMMER: 

DATE: 

LANGUAGE: 

INPUT: 

OUTPUT: 

PROCEDURE: 

TYPE: 

COMPUTER: 

ERROR  CODES: 
COMMON/LABEL  COMMON: 

EXTERNALS: 


Date  completed 

All  input  items 
All  output  items 


Specify  computer  or  state  that  it  is  machine  independent. 

Name  the  Common  and  list  the  acquirements,  otherwise 
specify  appendix  containing  the  explanation. 


B.3  Subroutine  Documentation 


This  narrative  is  similar  to  the  program  documentation.  It  shall  include  the  calling  sequence 
plus  an  explanation  of  the  arguments,  and  name  of  calling  routine. 

The  following  titles  shall  be  used: 


SUBROUTINE  NAME: 

PROGRAMMER: 

DATE: 

LANGUAGE: 

CALLING  SEQUENCE:  Call  Subname  (A,B,C) 

COMMON/LABEL  COMMON:  Same  as  in  program  documentation 


ARGUMENT  DESCRIPTION: 


PROCEDURE. 
EXTERNALS: 
INPUT/OUTPUT: 
ERROR  CODES: 


Define  in  order,  explain  each  item  and  identify  as  to  in¬ 
put,  output,  or  update.  This  explanation  shall  include  any 
unique  characteristics  of  the  argument,  such  as  data  type, 
array  length  and  use. 


B/i  Overall  Requirements 


All  mnemonic  names  shall  be  explained.  AH  programs  shall  be  indexed  as  to  function  along 
with  cross  indexing.  The  documentation  shall  be  updated  when  the  program  is  changed.  This  shall 
be  done  by  revising  the  existing  document. 

B.3  Comments  in  the  Code 


The  following  comments  are  required  in  all  programs: 

a.  A  paragraph  located  in  the  beginning  of  the  code  consisting  of  a  brief  descripton  of  the 
purpose  of  the  routine,  input  and  output  variables,  and  stop  codes.  This  paragraph  shall  be  set  off 
with  blank  lines. 


b.  A  statement  which  has  the  programmer’s  name  and  the  library  where  the  routine  is  located 
(if  applicable).  The  date  the  program  was  written  shall  also  be  included,  along  with  version  and  revision 
dates.  Version  one  is  the  first  production  version,  after  which  revisions  shall  be  added  without  remov¬ 
ing  the  previous  lines.  This  statement  shall  have  the  revision  number,  date,  and  programmer  name. 
There  shall  also  be  a  line  telling  which  computer  the  program  is  written  for,  and  if  it  contains  non 
standard  code. 

c.  High  level  language  programs  shall  have  comments  describing  each  function.  It  is  suggested 
the  maximum  number  of  lines  of  code  without  comments  be  limited  to  ten.  A  comment  line  shall 
precede  a  call  to  a  subroutine.  This  line  shall  tell  what  the  subroutine  does.  In  variable  entry  point 
subroutines,  there  shall  be  a  comment  line  telling  the  name  of  the  subroutine  which  contains  the  entry 
point.  All  comments  shall  be  set  off  with  blank  comment  lines  and  the  comments  shall  be  indented 
at  least  three  places  from  the  start  of  the  code. 

d.  Assembly  Language  programs  shall  contain  comments  following  the  statements.  These  com¬ 
ments  shall  describe  the  logic,  not  the  instructions.  When  calling  an  Assembly  subroutine  from  a  pro¬ 
gram.  the  storage  locations  of  the  subroutine  parameters  shall  be  identified  by  comments  in  the  Assembly 
routine. 

e.  All  debugging  aids  such  as  extra  prints  and  dumps  shall  be  made  non-executive  statements 
at  the  time  of  acceptance. 

f.  Updates  to  source  libraries  shall  be  correlated  with  revision  dates. 

Example: 

VERSION  1 

REVISION  1  DATE -PROGRAMMER 
B/>  Appendices 

A  detailed  description  of  all  files,  tables,  special  formats  of  tapes  or  cards,  label  and  blank 
common,  and  the  math  models  used  shall  be  included  in  the  appendix.  Each  item  shall  be  referenced 
for  easy  identification  and  the  items  shall  be  listed  as  a  separate  appendix. 

All  mathematical  analyses  shall  be  performed  and  explained  in  the  software  documentation 
to  the  extent  that  the  actual  code  being  documented  could  be  written  directly  from  the  documentation. 

The  appendices  shall  include  a  detailed  description  of  the  format  needed  to  use  files,  tapes, 
or  tables.  Each  item  making  up  the  file,  table,  etc.,  shall  be  explained  as  to  its  function  and  purpose. 
Any  unique  or  specific  assignment  shall  also  be  listed.  An  example  would  be:  "Tape  2  for  input  only". 

All  types  of  Common  shall  be  listed  in  the  appendix.  Each  item  shall  be  described  as  explained 
under  the  subroutine  documentation  for  the  calling  parameters.  Any  common  which  is  used  only  be¬ 
tween  two  routines  shall  be  listed  and  explained  with  the  routine  as  well  as  in  the  appendix.  If  reusing 
words  in  common  or  arrays  for  different  purposes  in  a  subroutine,  this  shall  be  fully  explained  for 
each  routine. 
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APPENDIX  C 


ANALYSIS  OF  NON-ROMAN  SCRIPT  PROCESSING 


C.l  Overview  of  Non-Roman  Script 

Non-Roman  scripts  fall  into  three  groups: 

-alphabets,  where  characters  each  represent  a  given  sound  or  sounds; 

-ideographies,  where  characters  represent  ideas; 

-syllabaries,  where  characters  represent  syllables. 

C.1.1  Non  Roman  Alphabets 

The  major  non-Roman  alphabets  of  interest  for  names  processing  purposes  are:  Arabic,  Ger¬ 
man,  Greek,  Hebrew,  Cyrillic,  and  Korean.  Table  C-l  shows  an  analysis  of  these  alphabets. 


Table  C-l.  Analysis  of  Alphabets 


Alphabet 

Upper  Case 

Lower  Case 

#  Symbols 

Digitized 

Arabic 

28 

N/A 

28 

N 

German 

29 

29 

58 

Y 

Greek 

24 

24 

48 

Y 

Hebrew 

28  (1) 

N/A 

28 

N 

Cyrillic 

31 

31 

62 

Y 

Korean  (2) 

— 

— 

— 

N 

(1)  Includes  word-ending  versions  of  kaph,  mem,  nun,  pe,  and  sadi. 

(2)  Information  not  available  at  time  of  publication.  This  alphabet  is  based  on  Sanskrit  forms. 

C.l. 2  Ideographies  and  Syllabaries 

Chinese,  Japanese,  and  Thai  are  the  important  ideographies  to  consider  for  electronic  names 
processing.  Chinese  and  Japanese  character  sets  are  fundamentally  the  same,  since  previous  to  the 
introduction  of  Chinese  characters  to  Japan  (at  the  time  of  the  introduction  of  Buddhism  and  Confu 
cianism)  there  was  no  written  Japanese  language. 

Chinese  characters  are  called  Kanji  by  the  Japanese.  There  are  approximately  5500  Chinese 
characters  of  common  occurance  in  modern  literature,  and  far  more  in  classical  literature.  Many  of 
the  Kanji  have  been  simplified.  A  set  of  1850  selected  Kanji,  called  “Toyo  Kanji”  (current  characters), 
are  used  in  newspapers  and  official  documents,  These  are  unlikely  to  suffice  for  names  applications. 


(3)  This  analysis  of  Kanji  was  taken  from  A.V.  Hershey,  “Calligraphy  for  Computers,"  U.S. 
Naval  Weapons  Laboratory.  Dahlgren,  VA,  August  1967.  AD  662398. 
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Japanese  includes  two  phonetic  syllabaries.  The  phonetic  characters  are  called  “kana."  The 
“hiragana”  syllabary  is  used  for  inflection  and  the  “katakana”  syllabary  is  used  for  foreign  words 
or  telegrams.  There  are  48  characters  in  each  phonetic  syllabary.  Some  characters  may  be  modified 
by  diacritics  (nigori)  to  make  23  additional  characters. 

A  Chinese  character  is  constructed  with  one  or  more  parts.  A  “radical"  is  contained  in  every 
character.  There  are  214  radicals,  many  of  which  are  themselves  complete  characters.  Radicals  are 
used  as  the  key  to  a  Kanji  dictionary.  The  index  of  a  Kanji  dictionary  lists  all  radicals  serially  in  order 
of  increasing  number  of  strokes.  The  index  references  the  portion  of  the  dictionary  where  all  characters 
with  that  same  radical  are  listed  together  in  order  of  increasing  number  of  strokes.  Thus  to  look  up 
the  meaning  of  a  character  in  the  dictionary  the  radical  is  isolated,  located  in  the  index,  and  the  cor¬ 
responding  section  of  the  dictionary  is  scanned. 

A  Naval  Weapons  Lab  effort  (4)  resulted  in  digitization  of  the  katakana  and  hiragana  syllabaries 
and  a  set  of  Kanji  characters,  selected  as  follows. 

1.  Radicals  which  are  also  members  of  the  Toyo  Kanji  list. 

2.  Characters  taught  to  Japanese  children  in  the  first  grade. 

3.  Characters  of  scientific  interest. 


Digital  text  processing  tasks  can  be  broken  into  the  areas  below. 

1.  Data  capture 

2.  Storage 

3.  Retrieval 

4.  Edit 

3.  Hardcopy  reproduction 

The  means  of  character  representation  within  the  system  dictates  the  method  and  difficulty  of  perform¬ 
ing  each  of  the  processes  listed  above.  Character  representation  may  be  in  bit  map  or  image  form 
stored  in  a  character  field  in  the  database:  or  it  may  be  in  ASCII  code.  The  impacts  of  each  of  these 
means  of  character  representation  are  discussed  below. 

C.2.1  ASCII  Representation 

ASCII  codes  exist  for  all  non-roman  alphabets  and  for  all  ideograms  (3.6).  The  issues  surroun¬ 
ding  the  five  major  electronic  names  processing  tasks  using  ASCII  codes  are  as  follows. 


(4)  ibid.  A  character  found  to  be  a  component  of  two  or  more  compound  characters  was  digitized. 
If  one  of  a  pair  of  antomnyms  was  digitized,  its  opposite  was  also  digitized.  A  comprehensive  digitiza¬ 
tion  was  not  the  goal;  merely  an  illustrative  and  well  balanced  character  list  of  characters.  It  is  unknown 
how  this  character  set  compares  to  the  character  set  required  for  placenamcs  representation. 

(5)  Kanji  ASCII  requires  two  bytes.  If  a  code  does  not  exist  for  Thai,  one  is  easily  developed. 

(6)  The  Multiset  III  system  currently  supports  Greek.  Cyrillic,  and  Korean  in  ASCII,  making 
capture  of  ideograms  the  major  concern. 


C.2.1.a  Data  Capture 

At  minimum,  one  of  two  new  procedures  would  require  development  (7): 


1.  keyboard  chording  schemes  to  support  each  required  character  set: 

2.  data  entry  using  a  digitizing  tablet  divided  into  a  matrix  of  characters  (see  Figure  C-f). 
A  different  template  would  be  used  for  each  character  set. 

Of  the  two  procedures,  keyed  entry  is  a  reasonable  alternative  for  foreign  alphabets.  However, 
ideographic  character  sets  which  number  well  into  the  thousands  require  the  second  form  of  data  en¬ 
try-  Neither  procedure  holds  any  risk  but  represents  considerable  development  and  learning  time  for 
each  character  set. 

C.2.1.b  Data  Storage 

The  non-romanized  name  is  stored  in  ASCII  form  in  the  field  of  its  corresponding  Latin-alphabet 
name.  Currently.  Kanji  is  supported  by  Fujitsu  in  its  A1M/RDB  data  base.  It  requires  a  two  byte  code. 
No  other  such  non-roman  support  is  known. 

C.2.1.C  Data  Retrieval 


It  is  a  simple  matter  to  query  the  data  base  for  the  non-romanized  version  of  a  specified  romanized 
name.  One  of  the  data  entry  devices  discussed  in  Section  C.2.1.a  would  be  required  to  specify  the 
name  in  its  non-romanized  form.  If  alphabetic  sorting  on  the  non-romanized  names  is  required,  soft¬ 
ware  must  be  developed  for  the  task.  This  is  non  trivial  since  sorting  on  Kanji  moy  be  by  telephone 
book  order,  stroke  number,  and  a  several  other  different  ways. 

C.2.1.  d  Edit 

Editing  itself  is  straightforward  although  aw'kward  using  ASCII  codes  and  the  data  entry  devices 
discussed  in  Section  C.2.1. a.  Text  display  requires  digitized  symbol  forms  for  raster  display.  This  technology 
exists  in  the  font  digitization  procedures  developed  by  ETL.  There  would  be.  however,  an  outlay  for 
labor  and  quality  control  since  the  ideograms  digitized  are  unlikely  to  be  familiar  to  the  digitizer,  in 
creasing  the  risk  of  error. 

C.2.1.e  Hardcopy  Reproduction 

The  Multiset  III  computer  typesetter  is  capable  of  printing  any  character  given  its  ASCII  code 
and  the  correct  print  wheel.  Multiset  III  answers  tabular  needs  only  unless  map  names  are  to  be  placed 
manually.  Names  overlays  ci  n  be  produced  either  with  stick-up  type  from  Multiset  III  or  through 
digitizing  characters  for  the  CRT  printhead,  as  described  above. 

C.2.2  Bit  Map  Representation 

The  alternative  to  ASCII  character  representation  is  treating  each  non-romanized  name  as 
a  raster  image.  The  technology  and  tradeoffs  are  discussed  below. 


(7)  Automated  character  recogntion  is  not  recommended  for  this  application  due  to  numerous 
form  and  font  variations  over  the  foreign  character  sets. 
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C.2.2.a  Data  Capture 


The  greatest  advantage  in  bit  map  character  representation  is  realized  in  the  data  capture  pro¬ 
cess.  The  area  of  the  non-romanized  word  is  raster-scanned,  background  noise  is  removed  interactively 
if  necessary,  and  a  bit  map  of  the  word  is  character  encoded  for  storage. 

C.2.2.b  Data  Storage 


The  bit  map  itself  is  encoded  in  character  form  and  stored  in  the  data  base.  Length  of  the 
character  string  could  preclude  using  certain  commercial  DBMS'. 

C.2.2.C  Data  Retrieval 


It  is  virtually  impossible  to  retrieve  names  in  a  bit  map  non-roman  form  for  the  same  reasons 
that  OCR  technology  is  not  recommended  for  data  capture.  Template  matching  is  unlikely  to  work 
due  to  the  many  variations  in  form  of  non-roman  script.  Alternate  OCR  technology  would  be  pro¬ 
hibitive  to  develop. 

C.2.2.d  Edit 

Editing  the  raster  image  could  be  performed  in  one  of  two  ways  (neither  without  its  problems). 
The  first  method  is  to  substitute  the  incorrect  image  with  a  new  and  correct  raster  image.  A  conve¬ 
nient  means  of  raster  scanning  a  small  area,  possibly  via  wand,  is  required. 

The  second  method  is  to  develop  softcopy  graphic  edit  software  usable  by  an  analyst  fluent 
in  the  writtten  language  being  edited.  The  ideal  configuration  for  such  detailed  line  work  would  not 
come  without  development  expense. 

C.2.2.e  Hardcopy  Reproduction 

A  raster  hardcopy  device  is  required  to  print  the  raster  character  image.  Laser  printer/plotters 
newly  on  the  market  could  meet  tabular  hardcopy  needs.  The  CRT  printhead  could  be  used  for  names 
overlays. 

C.2.3  Analysis  of  Methods 

The  bit  map  method  is  greatly  preferred  if  all  types  of  non-roman  script  (i.e.  both  alphabets 
and  ideograms)  are  required.  However,  if  searching  upon,  sorting,  and  to  some  extent,  editing  of  non¬ 
roman  names  are  major  requirements  the  bit  map  method  is  unsuitable  since  it  would  required  com¬ 
plex  search  and  sort  algorithms  and  slow  graphic  edit  methods.  The  bit  map  method  is  recommended 
if  access  to  the  non-roman  version  of  a  name  only  through  its  romanized  version  satisfies  DMA  needs. 

The  ASCII  method  of  non-roman  character  representation  would  require  no  major  technological 
development.  It  would  require  a  great  deal  of  labor  and  practice  for  interactive  non-roman  ASCII  com¬ 
munication  and  display,  since  specialized  input  devices  must  be  developed  and  symbols  must  be  digitiz¬ 
ed  for  display.  There  do  exist  digitized  fonts  for  Cyrillic.  Arabic.  Greek,  and  possibly  Korean:  however 
digitization  of  ideograms  would  impose  strenuous  labor  requirements  to  development  of  ASCII  support. 

Equipment  requirements  for  either  method  are  likely  to  overlap  with  equipment  requirements 
fo  the  Geonames  Processing  System  as  a  whole. 
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